1. Field of the Invention
The present invention relates generally to computational systems and, more particularly, to security techniques for characterizing or categorizing, and (in some cases) interdicting, information flows that present possible security risks.
2. Description of the Related Art
The vulnerability of computer systems, configurations, software and information codings and protocols to unauthorized access or use is widely recognized, at least by information security professionals. In general, these vulnerabilities can range from minor annoyances to critical national security risks. Today, given the ubiquitous nature of internet communications and the value of information and transactions hosted on the public internet, vulnerabilities are discovered and exploited at alarming rates. Automated tools facilitate the probing of systems and discovery of vulnerable systems and configurations. Once vulnerabilities are identified, exploits can be globally disseminated and rapidly employed.
Often, exploits seek to compromise security by introducing into a target system, data that can or will be interpreted by the target system in a way that facilitates the attack. For example, one classic form of attack is the so-called buffer overflow attack, in which an exploit causes vulnerable code to write data to memory in such a way that locations beyond the ostensible write target are updated. Typically, the data written takes the form of an input string that includes data which, if successfully introduced into memory in a precise location, will be interpreted by executing code (typically privileged code) in a way that facilitates the exploit. For example, if a write operation improperly writes 2 KBytes of data to a 128 Byte data structure, memory locations may be updated beyond the data structure intended by the original programmer. If those memory locations include the stack or a pointer used by privileged code, an attacker may successfully alter an execution path of privileged code. Other exploits may modify data upon which privileged code relies. In any case, a precisely crafted input string can be used to compromise a computer system.
Vulnerability to such attack vectors generally results from poor programming practices and/or bugs. However, such vulnerabilities are surprisingly widespread in commercial off the shelf software. A majority of the most damaging internet “worms” have employed techniques that resulted in direct corruption of function-pointers. Two notable examples are the 1988 Morris Internet worm which exploited (amongst other vulnerabilities) an unchecked buffer write in the UNIX fingerd program and the 2003 Slammer worm which exploited a buffer overflow vulnerability in computers running Microsoft's SQL Server.
In general, the strategy (if not the specific vector) of such attacks is reasonably well understood and a variety of security techniques have been developed to detect and/or defeat some such attacks. Examples include stack canary techniques, such as employed in StackGuard™ (or StackGuard-inspired systems) and StackShield extensions to the Gnu C compiler, and constrained control-flow techniques, such as described by M. Abadi, M. Budiu, Ú. Erlingsson and J. Ligatti, Control-Flow Integrity, Microsoft Technical Report, MSR-TR-05-18 (October 2005) or proposed by V. Kiriansky, D. Bruening and S. Amarasinghe, Secure Execution Via Program Shepherding, in Proc. 11th USENIX Security Symposium (2002). However, techniques employed have typically required a binary-rewriting pass or worse, source code analysis.
Another security technique that has been proposed involves (1) modifications to processor hardware and related structures of a memory hierarchy to store and manage security tags and (2) modifications to operating system implementations to mark spurious input data. See e.g., G. E. Suh, J. Lee, D. Zhang and S. Devadas, Secure Program Execution via Dynamic Information Flow Tracking, in Proceedings of the 11th international Conference on Architectural Support For Programming Languages and Operating Systems (2004). Unfortunately, it is often not possible or practical to redesign CPUs (Central Processing Units) and modify operating systems.
Alternative techniques are desired.